The Cellular Internet of Things (CIoT) is a new radio technology that is able to provide extended coverage for harsh environments, for example, basements, and is designed to serve massive number of UEs (over 50,000 per base station) using a very limited bandwidth (e.g. 160 bps).
The aim is to be able to support highly efficient handling of frequent and infrequent small data transmissions with minimised overhead for system signalling, without compromising security. Contributors to the signalling overhead may be procedures required for UE state transition, for example at transitions between the Idle state and the Connected state. Although these procedures may be used when the UE is an IoT UE, which may require infrequent connection to the network, the procedures may be used for any type of UE.
In order to reduce the signalling overhead and the associated processing load in the network, a solution has been proposed that is based on the re-use of information from the previous RRC connection for the subsequent RRC connection setup.
The signalling overhead reduction is realized by introducing two new procedures ‘RRC Suspend’ and ‘RRC Resume’ and the introduction of a modified UE behaviour in new CIoT Idle state where relevant information is stored when the UE transitions to the Idle state, triggered by a RRC Suspend procedure, and re-used for a subsequent connection setup by the UE. Although examples are given here relating to cases where the UE is a CIoT UE, the ‘RRC Suspend’ and ‘RRC Resume’ procedures, or similar, can be used with any UE.
It is suggested to keep the Access Stratum Security Context in the eNB. At suspension of an RRC connection, the eNB instructs the UE how to derive the security key for the subsequent resumption, i.e. it provides the UE with the security algorithm configuration and the Next Hop Chaining Counter (NCC) associated with the KeNB that is to be used at subsequent resumption.
This may require that the KeNB is stored in the eNB for prolonged periods of time when the RRC connection is suspended. This increases the risk that the KeNB is leaked from eNB, which may be deployed in a vulnerable location. If an attacker would get hold of such leaked KeNB, she/she would be able to make malicious use of such KeNB as long the KeNB (or derivatives of such KeNB) are used to secure the communication between the UE and the eNB.